Non-retained message system

ABSTRACT

A system and method for non-retained electronic messaging is described. In one embodiment, the system includes a message receiver module, a message storing and identifier generation module, a message retrieval module and an expunging module. The message receiver module receives a message. The message storing and identifier generation module stores the message in a non-transitory, non-persistent memory of one or more computing devices, generates a message identifier and sends the message identifier to a recipient device. The message retrieval module receives a selection of the message identifier from the recipient device, retrieves the message from the non-transitory, non-persistent memory, and sends the message to the recipient device for presentation. The expunging module expunges the message from the one or more devices responsive to sending the message to the recipient device for presentation.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation in part of and claims priority toU.S. application Ser. No. 13/844,136, filed Mar. 15, 2013, titled“Non-Retained Message System,” which is incorporated by reference in itsentirety.

BACKGROUND

The specification relates to electronic messaging. In particular, thespecification relates to non-retained electronic messaging. Existinge-mail systems, involve sending messages through a complex network ofservers such as SMTP, IMAP and POP servers. When messages are sentthrough these servers, copies of the messages are often stored andretained for the purposes of delivery. Even after the messages have beendelivered, it is highly likely that numerous copies of the message areretained in the network, either as backups, cloud-based copies ofemails, archives, inboxes, junk mail, trash items, etc. In manycircumstances, especially where highly sensitive or confidentialmessages or documents are being transmitted, the goal is only tocommunicate to the receiving party and not have any of the informationretained anywhere else throughout the system. Having messages ordocuments retained, many times permanently, means that the communicatingparties have lost control of those messages and documents. Such a lossof control can lead to detrimental outcomes, including accidentaldisclosure of information, unwanted indications of communications andnumerous other undesirable consequences.

Similarly, social networking sites such as Facebook, Twitter, Google+,etc. retain content such as photographs, videos, text and other usercontent permanently or for a period outside the originator's control.There may be instances when an originator of content would like to postcontent for the purpose of sharing, but does not desire for the contentto be retained indefinitely or outside the originator's control.

SUMMARY

The specification overcomes deficiencies and limitations of the priorart at least in part by providing a system and method for non-retainedelectronic messaging.

The specification describes a system, method and computer programproduct for non-retained electronic messaging according to someembodiments. In one embodiment, the system comprises a message receivermodule, a message storing and identifier module, a message retrievalmodule and an expunging module. The message receiver module receives amessage. The message storing and identifier generation module stores themessage in a non-transitory, non-persistent memory of one or morecomputing devices, generates a message identifier and sends the messageidentifier to a recipient device. The message retrieval module receivesa selection of the message identifier from the recipient device,retrieves the message from the non-transitory, non-persistent memory andsends the message to the recipient device for presentation. Theexpunging module expunges the message from the one or more devicesresponsive to the message retrieval module sending the message to therecipient device for presentation.

In some embodiments, the expunging module expunges the messageidentifier from the one or more computing devices responsive to sendingthe message identifier to the recipient device. In some embodiments, themessage identifier and message are sent anonymously based on a userpreference associated with a sender of the message. In some embodiments,the message identifier is a URL. In some embodiments, the system lacks awritable, persistent memory. In some embodiments, the message identifierand message are sent to an e-mail client through a standard e-mailprotocol.

In some embodiments, the system includes a key generation module forgenerating a globally unique key. In some embodiments, the messageidentifier is based at least in part on the globally unique key. In someembodiments, the expunging module expunges the globally unique key fromthe one or more computing devices responsive to sending the messageidentifier to the recipient device, and receiving the selection of themessage identifier includes receiving the globally unique key.

In some embodiments, the system includes an index hashing module forgenerating a hashed index based at least in part on the globally uniquekey, and the message is stored in the non-transitory, non-persistentmemory using the hashed index. In some embodiments, the index is hashedbased at least in part on a device key, the device key associated with acomputing device comprising the non-transitory, non-persistent memory onwhich the message is stored. In some embodiments, the expunging moduleexpunges the hashed index from the one or more computing devicesresponsive to sending the message identifier to the recipient device.

In some embodiments, the system includes an index generation module forgenerating a globally unique index responsive to receiving the message.In some embodiments, the hashed index generated by the index hashingmodule is based at least in part on the globally unique index, theexpunging module expunges the globally unique index from the one or morecomputing devices responsive to sending the message identifier to therecipient device, the message identifier is based at least in part onthe globally unique index and receiving the selection of the messageidentifier includes receiving the globally unique index.

In some embodiments, the system includes a message encryption module forencrypting the message prior to storing the message in thenon-transitory, non-persistent memory. In some embodiments, a keygeneration module generates a globally unique key, the messageencryption module encrypts the message using an encryption key prior tostoring the message in the non-transitory, non-persistent memory,wherein the encryption key is based at least in part on the globallyunique key, and decrypts the message retrieved from the non-transitory,non-persistent memory prior to sending the message to the recipientdevice for presentation, and the expunging module expunges the globallyunique key and the encryption key from the one or more computing devicesresponsive to sending the message identifier to the recipient device,the message identifier based at least in part on the globally uniquekey, and wherein receiving the selection of the message identifierincludes receiving the globally unique key.

In some embodiments, the expunging module sets a timer based on a userdefined time period and expunges the message from the non-transitory,non-persistent memory of the one or more computing devices responsive toa failure to receive the selection of the message identifier from therecipient device within the user defined time period. In someembodiments, the expunging module sets a timer based on a system definedtime period for the system and expunges the message from thenon-transitory, non-persistent memory of the one or more computingdevices responsive to a failure to receive the selection of the messageidentifier from the recipient device within the system defined timeperiod.

The features and advantages described herein are not all-inclusive andmany additional features and advantages will be apparent in view of thefigures and description. Moreover, it should be noted that the languageused in the specification has been principally selected for readabilityand instructional purposes, and not to limit the scope of the subjectmatter disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments are illustrated by way of example, and not by way oflimitation in the figures of the accompanying drawings in which likereference numerals are used to refer to similar elements.

FIG. 1 illustrates a system for non-retained electronic messagingaccording to one embodiment.

FIG. 2A is a block diagram illustrating a computing device fornon-retained messaging according to one embodiment.

FIG. 2B is a block diagram illustrating a non-retention message serveraccording to one embodiment.

FIG. 3 is a block diagram illustrating a non-retained messaging moduleaccording to one embodiment.

FIG. 4 is a flow chart illustrating a method for non-retained electronicmessaging according to one embodiment.

FIG. 5 is a flow chart illustrating a method for non-retained electronicmessaging according to another embodiment.

FIG. 6A-6B is a flow chart illustrating a method for non-retainedelectronic messaging according to yet another embodiment.

FIG. 7 is a flow chart illustrating a method for verifying a recipientaccording to one embodiment.

FIG. 8 is a flow chart illustrating a method for generating a record andnotification of an event according to one embodiment.

DETAILED DESCRIPTION

A system and method for non-retained electronic messaging. In thefollowing description, for purposes of explanation, numerous specificdetails are set forth in order to provide a thorough understanding ofthe embodiments. It will be apparent, however, that the embodiments canbe practiced without these specific details. In other instances,structures and devices are shown in block diagram form in order to avoidobscuring the embodiments. For example, one embodiment is describedbelow with reference to user interfaces and particular hardware.However, the present embodiments may apply to different types ofcomputing device that can receive data and commands, and peripheraldevices providing services.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms including, for example, “processing” or “computing” or“calculating” or “determining” or “displaying” or the like, refer to theaction and processes of a computer system, or similar electroniccomputing device, that manipulates and transforms data represented asphysical (electronic) quantities within the computer system's registersand memories into other data similarly represented as physicalquantities within the computer system memories or registers or othersuch information storage, transmission or display devices.

The present embodiments also relate to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, including, but not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, and magnetic disks,read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, flash memories including USB keyswith non-volatile memory or any type of media suitable for storingelectronic instructions, each coupled to a computer system bus.

The embodiments can take the form of an entirely hardware embodiment, anentirely software embodiment or an embodiment containing both hardwareand software elements. An exemplary embodiment is implemented insoftware, which includes but is not limited to firmware, residentsoftware, microcode, etc.

Furthermore, the embodiments can take the form of a computer programproduct accessible from a computer-usable or computer-readable mediumproviding program code for use by or in connection with a computer orany instruction execution system. For the purposes of this description,a computer-usable or computer readable medium can be any apparatus thatcan contain, store, communicate, propagate, or transport the program foruse by or in connection with the instruction execution system,apparatus, or device.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modem and Ethernet cards are just a few of thecurrently available types of network adapters.

Finally, the algorithms and displays presented herein are not inherentlyrelated to any particular computer or other apparatus. Variousgeneral-purpose systems may be used with programs in accordance with theteachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present embodiments are notdescribed with reference to any particular programming language. It willbe appreciated that a variety of programming languages may be used toimplement the teachings of the embodiments as described herein.

System Overview

FIG. 1 illustrates a block diagram of a system 100 for non-retainedelectronic messaging. The illustrated system 100 includes client devices115 a, 115 b, and 115 n (also referred to collectively as client devices115 or individually as client device 115) that are accessed by users 125a, 125 b, and 125 n (also referred to collectively as users 125 orindividually as user 125), non-retained message (NRM) servers 101 a, 101b, and 101 c (also referred to collectively as NRM servers 101 orindividually as NRM server 101), a non-retained message directory server180, a third party server 190, and an authorization server 107. In theillustrated embodiment, these entities are communicatively coupled via anetwork 105. Although three client devices 115 are illustrated, anynumber of client devices 115 are available to any number of users 125.

The client devices 115 in FIG. 1 are used by way of example. While FIG.1 illustrates three client devices 115, the present specificationapplies to any system architecture having one or more client devices115. Furthermore, while only one network 105 is coupled to the clientdevices 115, the NRM servers 101 and the authorization server 107, inpractice any number of networks 105 can be connected to the entities.Furthermore, while only one non-retained message directory server 180 isshown, the system 100 can include any number of non-retained messagedirectory servers 180. Furthermore, while only one third party server190 is shown, the system 100 can include any number of third partyservers 190.

Furthermore, while only one authorization server 107 is shown, thesystem 100 can include any number of authorization servers 107. In oneembodiment, the system 100 includes multiple authorization servers 107addressed by a single URL, address or domain name. In one embodiment,the system 100 includes multiple authorization servers 107 fronted by aload balancer (not shown).

Furthermore, while FIG. 1 illustrates three NRM servers 101, the presentspecification applies to any system architecture having one or more NRMservers 101. In one embodiment, the system 100 includes NRM servers 101addressed by a single URL, address or domain name. In one embodiment,the system 100 includes multiple NRM servers 101 fronted by a loadbalancer.

In one embodiment, a non-retained messaging module 220 a is included inthe NRM server 101 a and is operable on the NRM server 101 a, which isconnected to the network 105 via signal line 104. In another embodiment,the non-retained messaging module 220 b is included in the NRM server101 b and is operable on the NRM server 101 b, which is connected to thenetwork 105 via signal line 106. In yet another embodiment, thenon-retained messaging module 220 c is included in the NRM server 101 cand is operable on the NRM server 101 c, which is connected to thenetwork 105 via signal line 108. It will be recognized that thenon-retained messaging module 220 a/220 b/220 c (referred to generallyas the non-retained messaging module 220) can be stored in anycombination of one or more NRM servers 101. In some embodiments thenon-retained messaging module 220 includes multiple, distributed modulesthat cooperate with each other to perform the functions described below.Details describing the functionality and components of the non-retainedmessaging module 220 are explained in further detail below with regardto FIG. 3.

The network 105 enables communications between client devices 115, theNRM servers 101 and the authorization server 107. Thus, the network 105can include links using technologies including, for example, Wi-Fi,Wi-Max, 2G, Universal Mobile Telecommunications System (UMTS), 3G,Ethernet, 802.11, integrated services digital network (ISDN), digitalsubscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCIExpress Advanced Switching, etc. Similarly, the networking protocolsused on the network 105 can include the transmission controlprotocol/Internet protocol (TCP/IP), multi-protocol label switching(MPLS), the User Datagram Protocol (UDP), the hypertext transportprotocol (HTTP), the simple mail transfer protocol (SMTP), the filetransfer protocol (FTP), lightweight directory access protocol (LDAP),Code Division Multiple Access (CDMA), Wideband Code Division MultipleAccess (WCDMA), Global System for Mobile communications (GSM),High-Speed Downlink Packet Access (HSDPA), etc. The data exchanged overthe network 105 can be represented using technologies and/or formatsincluding the hypertext markup language (HTML), the extensible markuplanguage (XML), JavaScript Object Notation (JSON), Comma SeparatedValues (CSV), etc. In addition, all or some of links can be encryptedusing conventional encryption technologies, for example, the securesockets layer (SSL), Secure HTTP (HTTPS) and/or virtual private networks(VPNs) or Internet Protocol security (IPsec). In another embodiment, theentities can use custom and/or dedicated data communicationstechnologies instead of, or in addition to, the ones described above.Depending upon the embodiment, the network 105 can also include links toother networks.

In one embodiment, the network 105 is a partially public or a whollypublic network, for example, the Internet. The network 105 can also be aprivate network or include one or more distinct or logical privatenetworks (e.g., virtual private networks, Wide Area Networks (“WAN”)and/or Local Area Networks (“LAN”)). Additionally, the communicationlinks to and from the network 105 can be wireline or wireless (i.e.,terrestrial or satellite-based transceivers). In one embodiment, thenetwork 105 is an IP-based wide or metropolitan area network.

In the illustrated embodiment, the client devices 115 a, 115 b and 115 nare coupled to the network 105 via signal lines 108, 112 and 114,respectively. The user 125 a can interact with the client device 115 a.Similarly, the user 125 b can interact with the client device 115 b, andthe user 125 n can interact with the client device 115 n. The NRM server101 a is communicatively coupled to the network 105 via signal line 104.The NRM server 101 b is communicatively coupled to the network 105 viasignal line 106. The NRM server 101 c is communicatively coupled to thenetwork 105 via signal line 108. The authorization server 107 iscommunicatively coupled to the network 105 via signal line 116. In oneembodiment, the authorization server 107 is communicatively coupled todata storage 130 via signal line 102. In one embodiment, thenon-retained message directory server 180 is communicatively coupled tothe network 105 via signal line 118. In one embodiment, the third partyservers 190 is communicatively coupled to the network via signal line122.

In one embodiment, the data storage 130 stores data and information ofeach user 125 of the system 100. In one embodiment, the stored data andinformation includes credentials associated with each user 125.Credentials may be based at least in part on one or more of what a user125 knows (e.g., a password), what a user 125 is and what a user 125possesses. Examples of credentials include but are not limited to a username and/or password, a user alias, e-mail address, a biometricidentifier, an electronic identifier or anything else capable ofidentifying a user 125 and/or an associated user account. In oneembodiment, which is discussed below, a storage device 214 (see FIG. 2)is included in the authorization server 107 (i.e. one embodiment of acomputing device 200) and the storage device 214 stores the data andinformation of users 125 of the authorization server 107.

In one embodiment, a client device 115 a/115 b/115 n is an electronicdevice having a messaging client 120 a/120 b/120 n (also referred tocollectively as messaging clients 120 or individually as messagingclient) for interacting with the various servers 101, 107 and clientdevices 115 of the system 100 via the network 105. The client device 115can be, for example, a laptop computer, a desktop computer, a tabletcomputer, a mobile telephone, a personal digital assistant (PDA), amobile email device, a portable game player, a portable music player, atelevision with one or more processors embedded therein or coupledthereto, or any other electronic device capable of accessing a network.It will be recognized that other types of client devices 115 arepossible. In one embodiment, the system 100 comprises a combination ofdifferent types of client devices 115. For example, a combination of apersonal computer, a mobile phone and a tablet computer. In oneembodiment, the system comprises a combination of different messagingclients 120. For example, messaging client 120 a is Messaging Client Aoffered by Company A, messaging client 120 b is Messaging Client Boffered by Company B and messaging client 120 c is Messaging Client Coffered by Company C. In one embodiment, the client device includes aweb browser (not shown). The user 125 is a human user of the clientdevice 115.

In one embodiment, the non-retained message directory server 180 locatesa NRM server 101 for storage and retrieval of a message by an NRM server101. In one embodiment, the non-retained message directory server 180communicates with the NRM servers 101 to determine which NRM serverswill store redundant copies of a message for back-up. In one embodiment,the non-retained message directory server 180 is not a separate server,but incorporated into an NRM server 101. For example, the messageback-up module 322, discussed below in reference to FIG. 3, determineswhich NRM servers 101 will store redundant copies of a message forback-up.

In one embodiment, the third party servers 190 is a server associatedwith a traditional messaging system (e.g. e-mail, instant message,social networks, micro-blogs, short message services (SMS), etc.) andprovides traditional messaging services (e.g. e-mailing, instantmessaging, social networking, micro-blogging, SMS messaging, etc.). Inone embodiment, the third party server 190 is used by the non-retainedmessaging system 100 to send a message identifier (not the messageitself) to a recipient. For example, a message identifier may be sent asa “tweet” on Twitter, as a post on Facebook, as a message on LinkedIn,as an e-mail via Gmail, as an SMS text message, etc. It should berecognized that the preceding are merely examples of traditionalmessaging services and others exist. The message identifier is discussedbelow in reference to FIG. 3. In one embodiment, messages storage andsending is exclusive to NRM servers 101 and a third party server 190 orother server (e.g. authorization server 107) is not used to send orstore a message.

Example Computing Device 200

FIG. 2A is a block diagram of a computing device 200 for non-retainingmessaging according to one embodiment. As illustrated in FIG. 2A, thecomputing device 200 includes a network adapter 202 coupled to a bus204. According to one embodiment, also coupled to the bus 204 are atleast one processor 206, memory 208, a graphics adapter 210, an inputdevice 212, a storage device 214. The memory 208 stores one or moremodules, which are executed by the processor 206. In one embodiment, thefunctionality of the bus 204 is provided by an interconnecting chipset.The computing device 200 also includes a display 218, which is coupledto the graphics adapter 210.

The processor 206 may be any general-purpose processor. The processor206 comprises an arithmetic logic unit, a microprocessor, a generalpurpose controller or some other processor array to perform computationsand execute code and routines. The processor 206 is coupled to the bus204 for communication with the other components of the computing device200. Processor 206 processes data signals and may comprise variouscomputing architectures including a complex instruction set computer(CISC) architecture, a reduced instruction set computer (RISC)architecture, or an architecture implementing a combination ofinstruction sets. Although only a single processor is shown in FIG. 2A,multiple processors may be included. The processing capability may belimited to supporting the display of images and the capture andtransmission of images. The processing capability might be enough toperform more complex tasks, including various types of featureextraction and sampling. The computing device 200 also includes anoperating system executable by the processor including but not limitedto WINDOWS®, MacOS X, Android or UNIX® based operating systems. It willbe recognized that other processors, operating systems, sensors,displays and physical configurations are possible.

The memory 208 is a non-transitory storage medium. The memory 208 holdsinstructions and/or data that may be executed by the processor 206. Inone embodiment, the instructions and/or data stored on the memory 208comprise code for performing any and/or all of the techniques describedherein. The memory 208 may be a dynamic random access memory (DRAM)device, a static random access memory (SRAM) device, flash memory orsome other memory device. In one embodiment, the memory 208 alsoincludes a non-volatile memory or similar permanent storage device andmedia, for example, a hard disk drive, a floppy disk drive, a CD-ROMdevice, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flashmemory device, or some other mass storage device known for storinginformation on a more permanent basis. In some embodiments, the memory208 includes only volatile memory. The memory 208 is coupled by the bus204 for communication with the other components of the computing device200. In one embodiment, the computing device 200 is a NRM server 101 anda non-retained messaging module 220 is stored in memory 208 andexecutable by the processor 206. In one embodiment, the computing device200 is an authorization module 107 and an authentication module 240 isstored in the memory 208 and executable by the processor 206. In oneembodiment, the computing device 200 is a client device 115 and amessaging client 120 is stored in the memory 208 and executable by theprocessor 206.

In one embodiment, the computing device 200 is a NRM server 101 andincludes a non-retained messaging module 220. The non-retained messagingmodule 220, which is occasionally referred to herein as a “NRM module220,” includes code and routines executable by the processor 206 fornon-retained electronic messaging. In one embodiment, the non-retainedmessaging module 220 is a set of instructions executable by theprocessor 206. In another embodiment, the non-retained messaging module220 is stored in the memory 208 and is accessible and executable by theprocessor 206. Details describing the functionality and components ofthe non-retained messaging module 220 are explained in further detailbelow in reference to FIG. 3.

In one embodiment, the computing device 200 is an authorization server107 and includes an authentication module 240. The authentication module240 includes code and routines executable by the processor 206 forauthenticating credentials and authorizing use of the non-retainedmessaging system 100. In one embodiment, the authentication module 240is a set of instructions executable by the processor 206. In anotherembodiment, the authentication module 240 is stored in the memory 208and is accessible and executable by the processor 206.

The authentication module 240 authenticates credentials and authorizesuse of the non-retained messaging system 100. In one embodiment, theauthentication module 240 compares user credentials provided by a userto those stored by the authorization server 107 (e.g. in a data store130 or storage device 214 of the authorization server 107), andauthenticates the user if there is a match. In one embodiment, usercredentials include a username and password and the username and hashedpassword of each user is stored (e.g. as a flat file or relationaldatabase) in the data store 130 or storage device 214 of theauthorization server 107. In one embodiment, the passwords are hashed toprevent illegitimate acquisition and exploitation of the passwords by ahacker or other nefarious user. In one embodiment, multipleauthorization servers 107 are included in the non-retained messagingsystem 100 and the multiple authorization servers 107 share a commondatabase of user credentials. It will be recognized that otherembodiments may include credentials other than, or different from,username and password.

In one embodiment, the computing device 200 is a client device 115 andincludes a messaging client 120. The messaging client 120 includes codeand routines executable by the processor 206 for sending and receivingmessages over the non-retained electronic messaging system 100. In oneembodiment, the messaging client 120 is a set of instructions executableby the processor 206. In another embodiment, the messaging client 120 isstored in the memory 208 and is accessible and executable by theprocessor 206.

A messaging client 120 may include one or more of an e-mail client,instant messaging client, or any other messaging client. For thepurposes of clarity and simplification, many of the examples containedherein assume the messaging client 120 is an e-mail client. However, itwill be recognized that the description may be applied to other types ofmessaging clients 120 as well.

In one embodiment, the user configures the messaging client 120 in muchthe same way as the user would for a typical messaging service. Forexample, in one embodiment, the sender adds an e-mail server account tothe e-mail client in the same manner as any other e-mail account exceptthe outgoing mail server for the account is the address, or domain name,of the NRM servers 101.

In one embodiment, the messaging client 120 allows the user to compose amessage (e.g., including one or more of a subject, text, audio, video,images, files, attachments, etc.), identify a recipient and send themessage. In one embodiment, the user interfaces for composing a messageto be sent using the non-retained messaging system 100 may be identical,or nearly identical, to those for sending a traditional message usingthe messaging client 120. In one embodiment, the messaging client 120formats the message the same as a message to be sent on a traditionalmessaging system (e.g. e-mail, instant message, etc.). For example,assume the messaging client 120 is an e-mail client; in one embodiment,the e-mail client formats the message using a standard e-mail protocol(e.g. SMTP) for sending via the non-retained messaging system 100. Itwill be recognized that the preceding is merely an example of a formatand that others exist.

In one embodiment, the messaging client 120 receives and stores userpreferences locally on the client device 115. Examples of userpreferences include, but are not limited to, one or more of whether thesender of a message is identified to the recipient, a user defined timeperiod defining a message's lifespan on NRM server(s) 101 and event fromwhich the lifespan is measured. Some of these examples are discussedfurther below. It will be recognized that the preceding are merelyexamples and other examples of user preferences exist. In oneembodiment, the messaging client 120 allows a recipient user to locallysave or print a message sent via the non-retained message system 100. Inone embodiment, assuming a user decides not to locally save or print amessage delivered via the system 100, that message is permanently lostand unrecoverable, because messages are automatically expunged from thesystem 100 after retrieval/delivery.

The storage device 214 is any device capable of holding data, like ahard drive, compact disk read-only memory (CD-ROM), DVD, or asolid-state memory device. The storage device 214 is a non-volatilememory device or similar permanent storage device and media. The storagedevice 214 stores data and instructions for processor 206 and comprisesone or more devices including a hard disk drive, a floppy disk drive, aCD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, aflash memory device, or some other mass storage device. In oneembodiment, the storage device 214 stores data and information of a user125. For example, in one embodiment, the computing device 200 is anauthorization server 107 and the storage device 214 stores the user dataand information discussed above in reference to data storage 130 (e.g.credentials). In another example, in one embodiment, the computingdevice 200 is a client device 115 and the storage device 214 storesmessages.

The input device 212 may include a mouse, track ball, or other type ofpointing device to input data into the computing device 200. The inputdevice 212 may also include a keyboard, for example, a QWERTY keyboard,a graphical code scanner or any other physical or soft keyboard in anylanguage. The input device 212 may also include a microphone, a webcamera or similar audio or video capture device. The graphics adapter210 displays images and other information on the display 218. Thedisplay 218 is a conventional type, for example, a liquid crystaldisplay (LCD) or any other similarly equipped display device, screen,touchscreen or monitor. The display 218 represents any device equippedto display electronic images and data as described herein. The networkadapter 202 couples the computing device 200 to a local or wide areanetwork.

As is known in the art, a computing device 200 can have different and/orother components than those shown in FIG. 2A. For example, the computingdevice 200 can have speakers or another form of audio output. Inaddition, the computing device 200 can lack certain illustratedcomponents. For example, in one embodiment, the computing device 200 isan authorization server 107 and lacks an input device 212, graphicsadapter 210 and/or display 218. Moreover, the storage device 214 can belocal and/or remote from the computing device 200 (e.g., a storage areanetwork (SAN)).

Now referring to FIG. 2B, which illustrates a block diagram of a NRMserver 101 according to one embodiment. In one example, the computingdevice 200 is an NRM server 101 and according to the illustrated oneembodiment lacks an input device 212, storage device 214, graphicsadapter 210 and a display 218. Furthermore, according to one embodiment,a NRM server 101 includes a non-persistent memory 207 and a persistentmemory 205. The memories 205, 207 are coupled by the bus 204 forcommunication with the other components of the NRM server 101.

In one embodiment, the non-persistent memory 207 stores a message 230 a,230 n sent using the non-retained messaging system 100 pending deliveryto the recipient. In one embodiment, the non-persistent memory 207 isvolatile memory. Examples of volatile memory include, but are notlimited to, dynamic random access memory (DRAM) device, a static randomaccess memory (SRAM) device, a processor cache, etc.

In one embodiment, the NRM server 101 includes persistent memory 205 forstoring the non-retained messaging module 220. Examples of persistentmemory include non-volatile memory or similar permanent storage devicesand media, for example, a hard disk drive, a floppy disk drive, a CD-ROMdevice, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flashmemory device, or some other mass storage device for storing informationon a more permanent basis. In an exemplary embodiment, the persistentmemory 205 is a read only memory (ROM) and incapable of storing messagessent using the non-retained messaging system 100. In one embodiment, thecomputing device 200 is a NRM server 101 and a non-retained messagingmodule 220 is stored in the persistent memory 205 and executable by theprocessor 206. Since non-persistent memory 207 (e.g. RAM) is notpermanent and is generally more expensive and provides less capacitythan persistent memory 205 (e.g. a hard disk drive), embodiments inwhich the NRM server 101 lacks a writable, persistent memory orpersistent memory entirely may decrease the chances and dis-incentivizeretaining messages indefinitely on the non-retained messaging system100.

As is known in the art, the computing device 200 is adapted to executecomputer program modules for providing the functionality describedherein. As used herein, the term “module” refers to computer programlogic utilized to provide the specified functionality. Thus, a modulecan be implemented in hardware, firmware, and/or software. In oneembodiment, program modules are executed by the processor 206.

Embodiments of the entities described herein can include other and/ordifferent modules than the ones described here. In addition, thefunctionality attributed to the modules can be performed by other ordifferent modules in other embodiments. Moreover, this descriptionoccasionally omits the term “module” for purposes of clarity andconvenience.

Example Non-Retained Messaging Module 220

Referring now to FIG. 3, the non-retained messaging module 220 is shownin more detail according to one embodiment. FIG. 3 is a block diagram ofthe non-retained messaging module 220 included in a NRM server 101.

In one embodiment, the non-retained messaging module 220 comprises acommunications interface 302, a message receiver module 304, a messagestoring and identifier generation module 318, a message retrieval module322 and an expunging module 324. In some embodiments, the non-retainedmessaging module 220 optionally also includes one or more of anauthentication request module 306, a key generation module 308, an indexgeneration module 310, an index hashing module 312, an encryption keygeneration module 314, a message encryption module 316, a messageback-up module 320 a recipient verification module 326 and record andnotification module 328.

It will be recognized that the modules 302, 304, 306, 308, 310, 312,314, 316, 318, 320, 322, 324, 326, 328 comprised in the non-retainedmessaging module 220 are not necessarily all on the same NRM server 101.In one embodiment, the modules 302, 304, 306, 308, 310, 312, 314, 316,318, 320, 322, 324, 326, 328 are distributed across multiple NRM servers101. For example, in one embodiment, the message back-up module 316 isincluded in NRM server 101 a and the other modules 302, 304, 306, 308,310, 312, 314, 318, 320, 322, 324, 326 and 328 are included in NRMserver 101 b. It will be recognized that the preceding is merely anexample of distributing modules across multiple NRM servers 101 and thatother examples exist.

The communication interface 302 includes code and routines for handlingcommunications between the message receiver module 304, theauthentication request module 306 (depending on the embodiment), the keygeneration module 308 (depending on the embodiment), the indexgeneration module 310 (depending on the embodiment), the index hashingmodule 312 (depending on the embodiment), the encryption key generationmodule 314 (depending on the embodiment), the message encryption module316 (depending on the embodiment), the message storing and identifiergeneration module 318, the message back-up module 320 (depending on theembodiment), the message retrieval module 322, the expunging module 324,the recipient verification module 326 (depending on the embodiment), therecord and notification module 328 (depending on the embodiment) andother components of the NRM server 101. In one embodiment, thecommunication interface 302 is a set of instructions executable by theprocessor 206. In another embodiment, the communication interface 302 isstored in the persistent memory 205 and is accessible and executable bythe processor 206. In either embodiment, the communication interface 302is adapted for cooperation and communication with the processor 206,other components of the NRM server 101 and other components of thenon-retained messaging module 220.

The communication interface 302 handles communications between themessage receiver module 304, the authentication request module 306(depending on the embodiment), the key generation module 308 (dependingon the embodiment), the index generation module 310 (depending on theembodiment), the index hashing module 312 (depending on the embodiment),the encryption key generation module 314 (depending on the embodiment),the message encryption module 316 (depending on the embodiment), themessage storing and identifier generation module 318, the messageback-up module 320 (depending on the embodiment), the message retrievalmodule 322, the expunging module 324, the recipient verification module326 (depending on the embodiment), the record and notification module328 (depending on the embodiment) and other components of the NRM server101. For example, in one embodiment, the communication interface 202communicates with the key generation module 308 and the index hashingmodule 312 to pass the output of the key generation module 308 (i.e. aglobally unique key) to the index hashing module 312. However, thisdescription may occasionally omit mention of the communication interface302 for purposes of clarity and convenience. For example, for purposesof clarity and convenience, the above scenario may be described as thekey generation module 308 passing the globally unique key to the indexhashing module 312.

The message receiver module 304 includes code and routines for receivinga message. In one embodiment, the message receiver module 304 is a setof instructions executable by the processor 206. In another embodiment,the message receiver module 304 is stored in the persistent memory 205and is accessible and executable by the processor 206. In eitherembodiment, the message receiver module 304 is adapted for cooperationand communication with the processor 206, other components of the NRMserver 101 and other components of the non-retained messaging module220.

The message receiver module 304 receives a message. In one embodiment,the message receiver module 304 receives a message from a sending user'smessaging client 120. For simplicity and clarity, a user 125 sending amessage is occasionally referred to as a “sender.” For example, themessage receiver module 304 is communicatively coupled to receive themessage from the messaging client 120 of a sender's client device 115via the network 105.

A messaging client 120 may include one or more of an e-mail client,instant messaging client or any other messaging client. In oneembodiment, the message receiver module 304 receives a message from amessaging client 120 with little-to-no modification to the messagingclient 120. For example, in one embodiment, the message receiver module304 receives messages from an e-mail client such as Microsoft Outlook,Mozilla Thunderbird, Opera Mail, etc. Examples of little modificationinclude entering of an outgoing email server, entering of an emailaccount, installation of a plug-in, add-on, expansion pack, etc. It willbe recognized that the preceding examples are merely examples ofexisting, commercially available e-mail clients and that other examplesof messaging clients and e-mail clients exist.

In one embodiment, the message receiver module 304 receives a messageincluding a recipient identifier and a message corpus. The recipientidentifier is a unique identifier associated with the intended recipientof the sender's message. Examples of a recipient identifier include, butare not limited to, e-mail addresses, phone numbers, user names or anyother identifier associated with a user and unique within thenon-retained messaging system 100. The corpus of a message includes thecontent, which the sender wishes to communicate to the recipient. Themessage corpus may include, e.g., one or more of text, audio, video,images, files, attachments, etc.

In one embodiment, the received message has a format identical to thatof a message sent using a traditional messaging system. For example,assume the messaging client 120 is an e-mail client; in one embodiment,the message receiver module 304 receives a message formatted using astandard e-mail protocol (e.g. SMTP). It will be recognized that thepreceding is merely an example of a format and that others exist and maybe used without departing from the teachings herein.

In one embodiment, the message receiver module 304 passes the receivedmessage to the message storing and identifier generation module 318. Forexample, the message receiver module 304 is communicatively coupled tothe message storing and identifier generation module 318 to send thereceived message to the message storing and identifier generation module318. In another embodiment, the message receiver module 304 passes thereceived message to the message encryption module 316. For example, themessage receiver module 304 is communicatively coupled to the messageencryption module 316 to send the received message to the messageencryption module 316.

In some embodiments, it may be desirable to authenticate users. Forexample, it may be desirable to authenticate a user in order for theuser to access the system 100 and/or a feature or functionality thereof.For example, it may be desirable to authenticate the user prior to oneor more of composing a message, sending a message, sending a messageidentifier, etc. In one such embodiment, the non-retained messagingmodule 220 includes an optional authentication request module 306.

The authentication request module 306 includes code and routines forrequesting user authentication. In one embodiment, the authenticationrequest module 306 is a set of instructions executable by the processor206. In another embodiment, the authentication request module 306 isstored in the persistent memory 205 and is accessible and executable bythe processor 206. In either embodiment, the authentication requestmodule 306 is adapted for cooperation and communication with theprocessor 206, other components of the NRM server 101 and othercomponents of the non-retained messaging module 220.

The authentication request module 306 requests user authentication. Insome embodiments, user authentication is based on credentials. In oneembodiment, the authentication request module 306 requests userauthentication from an authorization server 107. For example, assumethat the NRM server 101 does not store credentials, because, e.g., theNRM server 101 lacks a storage device 214 and writeable persistentmemory 205.

In one embodiment, the authentication request module 306 requests theuser's credentials and passes the credentials, received from the user125, to the authorization server 107 as part of the request for userauthentication. In another embodiment, the authentication request module306 passes a request for user authentication to the authorization server107, and the authorization server 107 requests and receives the user'scredentials. In either embodiment, the authorization server 107determines whether the user is authorized based at least in part on thecredentials and notifies the authentication request module 306. Forexample, the authorization server 107 determines whether the user isauthorized based on whether a username and password provided by the usermatch a username and associated password stored by the authorizationserver 107 and notifies the authentication request module 306 whetherthe user is authenticated or not.

In some embodiments, one or more of the modules of the non-retainedmessaging module 220 execute subject to user authentication. Forexample, in one embodiment, the message receiver module 304 executespending user authentication of the sending user. In another example, inone embodiment, the message storing and identifier generation module 318executes pending user authentication of the sending user.

In one embodiment, the authentication request module 306 passes the userauthentication to one or more of the other modules of the non-retainedmessaging module 220. For example, the authentication request module 306is communicatively coupled to one or more of the other modules of thenon-retained messaging module 220 to send the user authentication to oneor more of the other modules of the non-retained messaging module 220.

The optional key generation module 308 includes code and routines forgenerating a globally unique key for each message. In one embodiment,the key generation module 308 is a set of instructions executable by theprocessor 206. In another embodiment, the key generation module 308 isstored in the persistent memory 205 and is accessible and executable bythe processor 206. In either embodiment, the key generation module 308is adapted for cooperation and communication with the processor 206,other components of the NRM server 101 and other components of thenon-retained messaging module 220.

The key generation module 308 generates a globally unique key for eachmessage. A globally unique key is a single unique object that is uniquein the world across all computing devices. For example, in oneembodiment, the globally unique key is a random 128 bit number, whichhas 2¹²⁸ possibilities (approximately 3.48×10³⁸) and, therefore,extremely unlikely have conflicts or be guessed. In another example, theglobally unique key is generated similar to a Globally Unique Identifier(GUID).

In one embodiment, the key generation module 308 also generates a devicekey. A device key is a globally unique key. In one embodiment, thedevice key is extremely large so that the device key is virtuallyimpossible to be guessed or figured out. For example, in one embodiment,the device key is a random 128 bit number, which has 2¹²⁸ possibilities(approximately 3.48×10³⁸) and, therefore, extremely unlikely haveconflicts or be guessed. In another example, the device key is generatedsimilar to a Globally Unique Identifier (GUID). In one embodiment, thedevice key is known only to the NRM server 101 associated with thedevice key. For example, in one embodiment, the key generation module308 of NRM server 101 a generates a device key associated with and knownonly by NRM server 101 a, and the key generation module 308 of NRMserver 101 b generates a device key associated with and known only byNRM server 101 b. In one embodiment, the device key is associated with aNRM server 101, but known by at least one other NRM server 101.

In one embodiment, the device key is dynamic. For example, in someembodiments, the key generation module 308 generates a new device keyeach time at start-up of the NRM server 101 or after detecting an(un)authorized access and expunging the non-persistent memory of allmessages, keys, indexes, etc. In an alternative embodiment, the devicekey may be a static, unique key assigned by the manufacturer. Regardlessof whether the device key is static or dynamic, in some embodiments,each copy of a message that may exist on multiple NRM servers 101 (e.g.for back-up) may have a different hashed index and encryption key foreach copy of the same message on the various NRM servers 101, becauseeach NRM server 101 is associated with a different device key.

In one embodiment, the key generation module 308 passes the globallyunique key to one or more of the index hashing module 312, theencryption key generation module 314 and the message storing andidentifier generation module 318. For example, the key generation module308 is communicatively coupled to one or more of the index hashingmodule 312, the encryption key generation module 314 and the messagestoring and identifier generation module 318 to send the globally uniquekey to one or more of the index hashing module 312, the encryption keygeneration module 314 and the message storing and identifier generationmodule 318.

In one embodiment, the key generation module 308 passes the device keyto one or more of the index hashing module 312, the encryption keygeneration module 314 and the message storing and identifier generationmodule 318. For example, the key generation module 308 iscommunicatively coupled to one or more of the index hashing module 312,the encryption key generation module 314 and the message storing andidentifier generation module 318 to send the device key to one or moreof the index hashing module 312, the encryption key generation module314 and the message storing and identifier generation module 318.

The optional index generation module 310 includes code and routines forgenerating a globally unique index. In one embodiment, the indexgeneration module 310 is a set of instructions executable by theprocessor 206. In another embodiment, the index generation module 310 isstored in the persistent memory 205 and is accessible and executable bythe processor 206. In either embodiment, the index generation module 310is adapted for cooperation and communication with the processor 206,other components of the NRM server 101 and other components of thenon-retained messaging module 220.

The optional index generation module 310 generates a globally uniqueindex for each message. Generating a globally unique index is optionaland the non-retained message system 100 works and is secure without aglobally unique index. However, in one embodiment, generating a globallyunique index may increase the amount of effort necessary to locate anddecrypt a message thereby adding further security to the system.

In one embodiment, the index generation module 310 passes the globallyunique index to the index hashing module 312. For example, the indexgeneration module 310 is communicatively coupled to the index hashingmodule 312 to send the globally unique index to the index hashing module312.

The optional index hashing module 312 includes code and routines forgenerating a hashed index. In one embodiment, the index hashing module312 is a set of instructions executable by the processor 206. In anotherembodiment, the index hashing module 312 is stored in the memory 208 andis accessible and executable by the processor 206. In either embodiment,the index hashing module 312 is adapted for cooperation andcommunication with the processor 206, other components of the NRM server101 and other components of the non-retained messaging module 220.

The index hashing module 312 generates a hashed index. In oneembodiment, the index hashing module 312 generates a hashed index basedon a globally unique key. For example, in one embodiment, the indexhashing module 312 generates a hashed index by hashing the globallyunique key. In one embodiment, the index hashing module 312 generates ahashed index based on a globally unique key and a device key. Forexample, in one embodiment, the index hashing module 312 generates ahashed index by hashing the globally unique key as the salt and thedevice key.

In one embodiment, the index hashing module 312 generates a hashed indexbased on the globally unique key received from the key generation module308 and the globally unique index received from the index generationmodule 310. For example, in one embodiment, the index hashing module 312generates a hashed index by hashing the globally unique key as the saltand the globally unique index. For example, in another embodiment, theindex hashing module 312 generates a hashed index by hashing theglobally unique key as the salt in combination with the globally uniqueindex and device key.

In one embodiment, the index hashing module 312 passes the hashed indexto the message storing and identifier generation module 318. Forexample, the index hashing module 312 is communicatively coupled to themessage storing and identifier generation module 318 to send the hashedindex to the message storing and identifier generation module 318.

The encryption key generation module 314 includes code and routines forgenerating an encryption key. In one embodiment, the encryption keygeneration module 314 is a set of instructions executable by theprocessor 206. In another embodiment, the encryption key generationmodule 314 is stored in the persistent memory 205 and is accessible andexecutable by the processor 206. In either embodiment, the encryptionkey generation module 314 is adapted for cooperation and communicationwith the processor 206, other components of the NRM server 101 and othercomponents of the non-retained messaging module 220.

The encryption key generation module 314 generates an encryption key. Insome embodiments, the encryption key generation module 314 generates anencryption key for a message based on the globally unique key associatedwith that message. Therefore, in some embodiments, the encryption key isunique for each message.

In one embodiment, the encryption key generation module 314 generates anencryption key based on the globally unique key. For example, in oneembodiment, the encryption key generation module 314 generates anencryption key using the globally unique key. In one embodiment, theencryption key generation module 314 generates an encryption key basedon the globally unique key and the device key. For example, in oneembodiment, the encryption key generation module 314 generates anencryption key by combining the globally unique key and the device key,or using the device key as the encryption key and the globally uniquekey as the initialization vector for the encryption.

In some embodiments, which include both the index hashing module 312 andthe encryption key generation module 314, the encryption key generationmodule 314 generates an encryption key using a process different fromthat the index hashing module 312 uses to generate the hashed index. Forexample, in one embodiment, the encryption key generation module 314generates the encryption key using the globally unique key incombination with the device key and the index hashing module 312generates a hashed index by hashing the globally unique key as the saltcombined with the globally unique index and device key.

In one embodiment, the encryption key generation module 314 passes theencryption key to the message encryption module 316. For example, theencryption key generation module 314 is communicatively coupled to themessage encryption module 316 to send the encryption key to the messageencryption module 316.

The optional message encryption module 316 includes code and routinesfor encrypting a message. In one embodiment, the message encryptionmodule 316 is a set of instructions executable by the processor 206. Inanother embodiment, the message encryption module 316 is stored in thepersistent memory 205 and is accessible and executable by the processor206. In either embodiment, the message encryption module 316 is adaptedfor cooperation and communication with the processor 206, othercomponents of the NRM server 101 and other components of thenon-retained messaging module 220.

The message encryption module 316 optionally encrypts the messagereceived by the message receiver module 304. In one embodiment, theencryption module 316 encrypts the message received by the messagereceiver module 304 using the encryption key generated by, and receivedfrom, the encryption key generation module 314. In another embodiment,encryption module 316 encrypts the message using a different encryptionkey.

In one embodiment, the unencrypted message is deleted from thenon-persistent memory 207 responsive to encryption. For example, in oneembodiment, the unencrypted message is expunged by the expunging module324 responsive to encryption. In one embodiment, the encryption module316 decrypts a message retrieved by the message retrieval module 322.

In one embodiment, the message encryption module 316 passes theencrypted message to the message storing and identifier generationmodule 318 for storage in the non-persistent memory. For example, themessage encryption module 316 is communicatively coupled to the messagestoring and identifier generation module 318 to send the encryptedmessage to the message storing and identifier generation module 318.

The message storing and identifier generation module 318 includes codeand routines for storing a message, generating an identifier and sendingthe identifier to a recipient. In one embodiment, the message storingand identifier generation module 318 is a set of instructions executableby the processor 206. In another embodiment, the message storing andidentifier generation module 318 is stored in the persistent memory 205and is accessible and executable by the processor 206. In eitherembodiment, the message storing and identifier generation module 318 isadapted for cooperation and communication with the processor 206, othercomponents of the NRM server 101 and other components of thenon-retained messaging module 220.

The message storing and identifier generation module 318 stores themessage. In one embodiment, the message storing and identifiergeneration module 318 in the non-persistent memory 207 of an NRM server101. In one embodiment, the message storing and identifier generationmodule 318 receives the hashed index generated by the index hashingmodule 312 and stores the message using the hashed index as a handle forstoring and retrieving the message. Such an embodiment beneficiallyprovides an obfuscated index for storing the message. In one embodiment,the message stored by the message storing and identifier generationmodule 318 is an encrypted version of the message.

The message storing and identifier generation module 318 generates amessage identifier. The message identifier is a unique identifier havingan enormous number of potential values so that is virtually impossibleto guess or iterate a through to discover a valid identifier especiallysince a message is not retained indefinitely in the system 100. Themessage identifier is uniquely associated with a message stored in thenon-persistent memory 207 of at least one NRM server 101. In oneembodiment, the message identifier is a URL to the non-retainedmessaging system 100.

In embodiments where a globally unique key was generated by the keygeneration module 308 and used by the index hashing module 312 togenerate a hashed index and/or by the encryption key generation module314 to generate an encryption key, the message identifier includes theglobally unique key. For example, the message storing and identifiergeneration module 318 generates a URL containing the globally uniquekey.

In embodiments where a globally unique index was generated by the indexgeneration module 310 and used by the index hashing module 312 togenerate a hashed index, the message identifier includes the globallyunique index. For example, the message storing and identifier generationmodule 318 generates a URL containing the globally unique key andoptionally a globally unique index. In one embodiment, the URL is anon-descript HTTP URL. In one embodiment, the URL is a non-descriptHTTPS URL, which may beneficially provide greater security than a HTTPURL. It will be recognized that a URL is merely one example of a messageidentifier and other message identifiers exist.

The message storing and identifier generation module 318 sends themessage identifier to the recipient. In one embodiment, the message isnot sent using a third party server 190 (e.g. those of traditionalmessage services such as e-mail, which retains copies of the message).Instead, the message storing and identifier generation module 318 sendsthe message identifier using a third party server. For example, themessage storing and identifier generation module 318 sends the messageidentifier through a standard e-mail service hosted by third partyserver 190. In one embodiment, the message storing and identifiergeneration module 318 uses a gateway service, for example, an e-mailgateway service to avoid issues with spam filters and/or to balancenetwork load.

In some embodiments, responsive to sending the identifier, informationis expunged from the non-persistent memory of the NRM server(s) 101. Insome embodiments, the information expunged from the NRM server(s) 101ensures that the NRM server(s) do not have all the information toindependently identify, locate and decrypt the message. Such embodimentsmay beneficially prevent a message from being accessed by anyone otherthan the recipient. Examples of information that may be expunged includeone or more of the globally unique key, the globally unique index, thehashed index, the encryption key and the message identifier. Forexample, in one embodiment, the globally unique key, the globally uniqueindex, the hashed index, the encryption key and the message identifierare expunged from the NRM server(s) 101. In some embodiments, theinformation expunged from the NRM server(s) 101 and the messagingidentifier ensure that neither the NRM server(s) 101 nor the recipientof the messaging identifier have all the information to independentlyidentify, locate and decrypt the message. For example, the identifierincludes the globally unique key, but not the device key and the NRMserver 101 does not have the globally unique key, but has the devicekey.

The information expunged after the identifier is sent depends on theembodiment and what information exists. For example, a globally uniqueindex is not expunged when one was not generated (e.g. the non-retainedmessaging module 220 did not include the optional index generationmodule 310). In one embodiment, the information is expunged by theexpunging module 324 discussed below.

In some embodiments, the identity of the sender may not be shared withthe recipient. For example, the e-mail including the message identifierdoes not identify the sending user, but the message when retrieved andpresented may or may not identify the sender depending on theembodiment. In another example, the message retrieved by the messageretrieval module 322 and presented to the recipient user does notidentify the sending user. In one embodiment, whether the sending useris identified to the recipient and/or at what point is determined basedon a user preference of the sender and/or an administrator's setting(e.g. an administrator associated with an organization for whom thesender is an employee). In one embodiment, if the sending user is notidentified, the sender identified is the NRM server 101 containing theURL for the message. In another embodiment, if the sending user is notidentified, the system instead identifies an account for an organizationwith whom the sender is associated or an account for the public ingeneral. In one embodiment, a message is sent without sender identifyinginformation (i.e. not only is the sender not identified to therecipient, but there is no sender identifying information associatedwith the message and stored in the system 100). In some embodiments, anadministrator may control whether and to what degree users are able tosend messages anonymously using the system 100. For example, in oneembodiment, an administrator for Corporation A may set controls suchthat an individual user (e.g. Bob from accounting) or group of users(e.g. the accounting department) may not send messages anonymously.

In one embodiment, the message storing and identifier generation module318 passes the message identifier to a third party server 190. Forexample, the message storing and identifier generation module 318 iscommunicatively coupled to the third party server 190 to send themessage identifier to the recipient via the third party server 190.

The optional message back-up module 320 includes code and routines forproviding redundancy. In one embodiment, the message back-up module 320is a set of instructions executable by the processor 206. In anotherembodiment, the message back-up module 320 is stored in the persistentmemory 205 and is accessible and executable by the processor 206. Ineither embodiment, the message back-up module 320 is adapted forcooperation and communication with the processor 206, other componentsof the NRM server 101 and other components of the non-retained messagingmodule 220.

In some embodiments, the configuration of the NRM server 101 makes itmore likely for a message to be permanently lost prior to delivery thanin a traditional messaging system (e.g. e-mail). For example, in someembodiments, the NRM server 101 lacks persistent, writable storage andmessages are stored by non-persistent memory; therefore, a disruption inpower to the NRM server 101 (e.g. power outage or natural disaster) mayexpunge undelivered messages on that NRM server 101. In another example,in some embodiments, the NRM server 101 is configured to activelyexpunge all memory if the NRM server 101 is logged into in order toenhance security. Under such circumstances, the undelivered messageswould also be permanently lost.

In one embodiment, the message back-up module 320 provides redundancy bysending back-up information to at least one additional NRM server 101.Such an embodiment beneficially increases the chances the message isdeliverable even if a NRM server's memory is expunged. In oneembodiment, back-up information includes the message received from thesender's messaging client 120. For example, the message receiver module304 of NRM server 101 a receives a message and the message back-upmodule 320 automatically forwards a copy of the received message to NRMserver 101 b where the message receiver module 304 of NRM server 101 breceives the copy.

In some embodiments, when a globally unique key associated with areceived message is generated by the key generation module 308, thatglobally unique key is back-up information and is sent by the back-upmodule 320 to at least one other NRM server 101. For example, in oneembodiment, the message receiver module 304 of NRM server 101 a receivesa message, the key generation module 308 generates a globally unique keyfor that message and the message back-up module 320 automaticallyforwards a copy of the received message and the globally unique key toNRM server 101 b.

In some embodiment, when a globally unique index associated with areceived message is generated by the index generation module 310 andassociated with a received message, that globally unique index isback-up information and is sent by the back-up module 320 to at leastone other NRM server 101. For example, in one embodiment, the messagereceiver module 304 of NRM server 101 a receives a message, the keygeneration module 308 generates a globally unique key for that message,the index generation module 310 generates a globally unique index forthe message and the message back-up module 320 automatically forwards acopy of the received message, the globally unique key and the globallyunique index to NRM server 101 b.

In some embodiments, any hashed index or encryption key generated forthe at least one other NRM server 101 (e.g. NRM server 101 b) will bedifferent from the hashed index or encryption key for the NRM server 101that originally received the message (e.g. NRM server 101 a) regardlessof whether the same globally unique key and/or globally unique index isforwarded and used, because each NRM server 101 is associated with adifferent device key.

Unlike traditional messaging systems, such as e-mail, any redundantmessages, also occasionally referred to herein as “back-ups,” “copies”or the like are expunged from the non-retained messaging system 101when, depending on the embodiment, the message is retrieved by themessage retrieval module 322, the message is delivered for presentationto the recipient or the lifespan of the message expires.

In one embodiment, the message back-up module 320 passes back-upinformation to at least one other NRM server 101. For example, themessage back-up module 320 is communicatively coupled to at least oneother NRM server 101 to send the back-up information to at least oneother NRM server 101.

The message retrieval module 322 includes code and routines forretrieving a message. In one embodiment, the message retrieval module322 is a set of instructions executable by the processor 206. In anotherembodiment, the message retrieval module 322 is stored in the persistentmemory 205 and is accessible and executable by the processor 206. Ineither embodiment, the message retrieval module 322 is adapted forcooperation and communication with the processor 206, other componentsof the NRM server 101 and other components of the non-retained messagingmodule 220.

The message retrieval module 322 retrieves a message using theidentifier. In one embodiment, the message retrieval module 322retrieves a message using the identifier responsive to the selection ofthe identifier. For example, assume the message identifier is a HTTPSURL which was sent to the recipient via e-mail. In one embodiment, therecipient receives the e-mail, opens the e-mail and selects the HTTPSURL, the message retrieval module 322 receives the HTTPS URL responsiveto the selection and retrieves the associated message and sends thatmessage for presentation to the user (e.g. in a messaging client 120 orweb browser (not shown) window). In one embodiment, the messageretrieval module 322 retrieves a message using the identifier responsiveto the selection of the identifier and verification of the recipient asdescribed below with reference to the recipient verification module 326.

Since many modules of the non-retained messaging module 220 areoptional, many combinations of modules and, therefore, embodimentsexist. The steps the message retrieval module 322 takes to retrieve amessage vary depending on the embodiment and which, if any, optionalmodules (e.g. 308, 310, 312, 314, 316, 326 and 328) are included in thenon-retained messaging module 200. For example, assume that thenon-retained messaging module 220 includes an index hashing module 312;in one embodiment, the message retrieval module 322 retrieves a messageusing a globally unique key included in the message identifier to obtainthe hashed index for retrieving the message from the non-persistentmemory. In another example, assume that the non-retained messagingmodule 220 includes an encryption module 316; in one embodiment, themessage retrieval module 322 retrieves an encrypted version of themessage and must obtain a decrypted version prior to sending the messagefor presentation to the user. In yet another example, assume that thenon-retained messaging module 220 includes a recipient verificationmodule 326; in one embodiment, the message retrieval module 322retrieves the message responsive to the recipient verification module326 determining that the user who selected the identifier is one or moreof human and the intended recipient.

In one embodiment, the message retrieval module 322 retrieves a messageusing the identifier in combination with a device key. For example, inone embodiment, the message retrieval module 322 passes the globallyunique key (and, depending on the embodiment, globally unique index)from the URL to the index hashing module 312 which retrieves the devicekey associated with the NRM server 101 and generates the hashed indexthat was used to store the message. The message retrieval module 322retrieves the message using the hashed index as a handle.

Depending on the embodiment, the message the message retrieval module322 retrieves is encrypted and needs to be decrypted. In one embodiment,the message retrieval module 322 passes the globally unique key to theencryption key generation module 314 which retrieves the device keyassociated with the NRM server 101 and generates the encryption key usedto decrypt the message. In one embodiment, the message retrieval module322 decrypts the message itself. For example, the message retrievalmodule 322 receives the encryption key from the encryption key module314 and decrypts the message. In another embodiment, the messageencryption module 316 receives the encryption key and decrypts themessage.

The message retrieval module 322 sends the message for presentation tothe user 125 based on the identifier. For simplicity and clarity, a user125 that is presented a message sent using and retrieved from thenon-retained messaging system is occasionally referred to as a“recipient.” For example, assume the message identifier is a URL; in oneembodiment, the message retrieval module 322 sends the message to thelocation associated with the URL for presentation to the recipient. Inone embodiment, when the message is presented to the recipient, themessage has a similar visual format of an e-mail. For example, themessage is presented via the messaging client 120 or web browser with asubject line, message body and attachments.

In one embodiment, the message retrieval module 322 passes informationincluded in the message identifier (e.g. a globally unique key) receivedresponsive to selection of the message identifier by the recipient userto one or more of the other modules (e.g. 312, 314, 316) of thenon-retained messaging module 220 in order to retrieve the message andsend the message for presentation. For example, the message retrievalmodule 322 is communicatively coupled to the index hashing module 312 topass the received globally unique key to the index hashing module 312 inorder to obtain the handle for retrieving the message (i.e. the hashedindex).

In one embodiment, the message retrieval module 322 passes a message forpresentation to a recipient user. For example, the message retrievalmodule 322 is communicatively coupled to the messaging client 120, orweb browser, of the client device 115 of the recipient to send themessage to the messaging client 120, or web browser, of the clientdevice 115 of the recipient. In one embodiment, the message retrievalmodule 322 passes an indication that the message has been retrieved tothe expunging module 324. For example, the message retrieval module 322is communicatively coupled to the expunging module 324 to send theindication that the message has been retrieved to the expunging module324.

The expunging module 324 includes code and routines for expungingmessages from a NRM server 101. In one embodiment, the expunging module324 is a set of instructions executable by the processor 206. In anotherembodiment, the expunging module 324 is stored in the persistent memory205 and is accessible and executable by the processor 206. In eitherembodiment, the expunging module 324 is adapted for cooperation andcommunication with the processor 206, other components of the NRM server101 and other components of the non-retained messaging module 220.

The expunging module 324 expunges messages from a NRM server 101. In oneembodiment, the expunging module 324 expunges a message from an NRMserver 101 responsive to the retrieval of the message. For example,assume the expunging module 324 receives an indication from the messageretrieval module 322 that the message has been retrieved for delivery orthe expunging module 324 itself detects that the message retrievalmodule 322 detects retrieval of the message for delivery; in oneembodiment, the expunging module 324 expunges the message from the NRMserver(s) 101 storing that message.

In one embodiment, the expunging module 324 expunges a message from anNRM server 101 responsive to the delivery of the message. For example,assume the expunging module 324 receives an indication from the messagemessaging client 120, or web browser, that the message has beenreceived; in one embodiment, the expunging module 324 expunges themessage from the NRM server(s) 101 storing that message. In oneembodiment, expunging the message includes expunging sender and receiverinformation responsive to retrieval or delivery. In other words, in oneembodiment, the non-retained messaging system 100 does not retain anysender or receiver information including logs of who sent whom amessage.

In one embodiment, the expunging module 324 expunges a message from anNRM server 101 responsive to an expiration of a time period associatedwith the message. The expiration of a time period associated with themessage is occasionally referred to herein as the “message exceeding itslifespan” or the like. In one embodiment, the time period, which isoccasionally referred to herein as a message's “lifespan,” is userdefined. For example, assume the user specifies a time period using themessaging client 120, and the time period is stored on the client device115 (e.g. as a user preference) and sent with each outgoing message sentusing that messaging client 120; in one embodiment, the expunging module324 receives the user defined time period and sets a timer accordingly.When the timer expires (i.e. the user defined time period has passed),the expunging module 324 expunges the message from the NRM server(s) 101assuming the message has not already been expunged (e.g., the messagewas retrieved and expunged from the NRM server(s) 101 responsive toretrieval and prior to the expiration of the timer). Depending on theembodiment, the user may define a time period for each individualmessage or define a time period to be used for all outgoing messagesunless redefined. Embodiments which provide for message expungementafter a user defined time beneficially allow a user to ensure that amessage is not available on the NRM server(s) 101 when the user nolonger wants the message available.

In one embodiment, the time period is system defined. In one embodiment,the system defined time period includes a default used when a userdefined time period has not been set. For example, does not define amessage lifespan; in one embodiment, the expunging module 324 sets adefault timer that is system defined. When the default timer expires,the expunging module 324 expunges the message from the NRM server(s) 101assuming the message has not already been expunged.

In one embodiment, the system defined time period defines a maximummessage lifespan. For example, in one embodiment, the expunging module324 sets a timer that is system defined, and when the system definedtimer expires, the expunging module 324 expunges the message from theNRM server(s) 101 assuming the message has not already been expunged andregardless of whether the user defined timer has expired. Embodimentswhich provide for message expungement after a system defined maximumtime period beneficially reduce the costs of running the NRMS system100. For example, non-persistent memory 207 is often more expensive perbyte of capacity than persistent storage; therefore, a higher memoryturn-over rate is desirable, because removing messages that have notbeen retrieved after a certain period of time so that the non-persistentmemory 207 may be used by other messages may avoid the cost of addingadditional NRM servers 101 and/or non-persistent memory 207 toaccommodate messages which may never be retrieved. Embodiments whichprovide for message expungement after a system defined maximum timeperiod may also provide additional security to the NRMS system 100 bylimiting the amount of time a hacker or other nefarious entity couldpotentially access the message en route from the sender to therecipient.

A time period, regardless of whether the time period is user defined orsystem defined, may be measured from one of a plurality of events.Examples of events include, but are not limited to receipt of themessage, sending of the identifier associated with the message to therecipient, retrieval of the message and delivery of the message.Embodiments in which the time period is measured from the retrieval ordelivery of the message may potentially allow a recipient anotheropportunity to receive the message should an error occur duringretrieval or delivery of the message.

In one embodiment, the expunging module 324 expunges a message from aNRM server 101 responsive to receiving a retraction request from thesender. In one embodiment, the retraction request includes the messageidentifier of the message the sender wishes to expunge and the expungingmodule 324 identifies and expunges the message associated with thatidentifier from the NRM server(s) 101 storing the message. In oneembodiment, a sender may request to retract a message prior to arecipient's retrieval of the message and the expunging module 324expunges that message responsive to the retraction request. For example,assume a sender sent a message by mistake and requests to retract thatmessage; in one embodiment, the expunging module 324 receives theretraction request, identifies the relevant message, determines that themessage has not been retrieved by the message retrieval module 322 andexpunges the message from the NRM server(s) 101 storing the message,thereby making the message no longer available.

In one embodiment, a sender may request to retract a message even afterthe message is retrieved and delivered to a recipient. For example,assume a message is retrieved prior to the expiration of the message'slifespan but not immediately expunged by the expunging module 324responsive to retrieval; in one embodiment, the expunging module 324 mayreceive a retraction request from the sender in the time between themessage's retrieval and the expiration of the message's lifespan andexpunge the message early (i.e. responsive to the retraction request andprior to the expiration of the time period defined by the lifespan).

In one embodiment, the expunging module 324 expunges other informationfrom the NRM server 101 in addition to messages. Examples of otherinformation include, but are not limited to one or more of the globallyunique key, index and message identifier, the encryption key,un-encrypted message, the sender, the recipient. For example, in oneembodiment, responsive to sending the message identifier associated witha message, the expunging module 324 expunges the globally unique key andmessage identifier associated with that message from the NRM server 101ensuring the NRM server lacks the necessary information to independentlyidentify and locate the message.

In one embodiment, the expunging module 324 expunges everything frommemory responsive to detecting an unauthorized access of the NRM server101. For example, assume the NRM server 101 detects predetermined numberof failed login attempts using a system administrator's username; in oneembodiment, the NRM server 101 expunges everything from memory. In oneembodiment, the expunging module 324 expunges everything from memoryresponsive to detecting an access of the NRM server 101 regardless ofwhether the access is authorized or unauthorized. For example, assumethe NRM server 101 detects a successful system administrator login; inone embodiment, the NRM server 101 expunges everything from memoryresponsive to detecting the login.

The expungement impedes access to the expunged data. The expungement theexpunging module 324 performs may vary depending on the embodiment.Examples of expungement include, but are not limited to, removinghandles (e.g. pointers) to the expunged data, overwriting the expungeddata with new data (e.g. a new message or writing to zero) or any othermethod of wiping data from memory, which allows the memory to be reused.

The optional recipient verification module 326 includes code androutines for verifying a recipient user prior to retrieving andpresenting the message to the recipient user. In one embodiment, therecipient verification module 326 is a set of instructions executable bythe processor 206. In another embodiment, the recipient verificationmodule 326 is stored in the persistent memory 205 and is accessible andexecutable by the processor 206. In either embodiment, the recipientverification module 326 is adapted for cooperation and communicationwith the processor 206, other components of the NRM server 101 and othercomponents of the non-retained messaging module 220.

The recipient verification module 326 verifies a recipient user prior toretrieving and presenting the message to the recipient user. In oneembodiment, the recipient verification verifies that the recipient user(i.e. the user that selected the message identifier) is one or more ofhuman and the intended recipient. Such recipient verification maybeneficially provide further security to the non-retained messagingsystem 100 by further reducing the possibility of unauthorized access toa message sent via the non-retained messaging system 100.

In one embodiment, the recipient verification module 326 verifies that arecipient is human. In one embodiment, the recipient verification module326 verifies that the recipient is human (rather than, for example, abot, crawler, computer or other automated, non-human reader) using aCompletely Automated Public Turing test to tell Computers and HumansApart (CAPTCHA). In some embodiments, the CAPTCHA may be auditory,visual or a combination. For example, in one embodiment, the recipientverification module 326 presents a visual CAPTCHA in the form of anon-screen, human-only readable challenge to the recipient responsive toselection of a message identifier. In another example, the recipientverification module 326 presents an auditory CAPTCHA in the form of ahuman-only intelligible audio challenge to the recipient responsive toselection of a message identifier. The recipient verification module 326receives a recipient's response to the presented CAPTCHA challenge, anddetermines whether the response matches the challenge. In oneembodiment, the message retrieval module 322 retrieves the message basedat least in part on whether the recipient verification module 326determines that the response matches the challenge. In one embodiment,the message retrieval module 322 does not retrieve the message when therecipient verification module 326 determines that the response does notmatch the challenge.

In one embodiment, the recipient verification module 326 determineswhether to verify that a recipient is human based on a sender'spreference. For example, a sender may set a preference to verify thehumanity the recipient for all messages or for messages to a particularrecipient or group of recipients, and the recipient verification module326, responsive to selection of the message identifier, determineswhether the message is flagged for recipient verification based on thesender's preference and presents (or does not present) a challengeaccordingly. In one embodiment, the recipient verification module 326determines whether to verify that a recipient is human automatically andwithout user intervention. For example, recipient verification module326 determines to challenge the recipient, when the selection of theidentifier is received from an unfamiliar location (e.g. an IP addressor device not previously used by or associated with the recipient).

In one embodiment, the recipient verification module 326 verifies that arecipient is the intended recipient. In one embodiment, the recipientverification module 326 verifies that the recipient is the intendedrecipient using verification information. Verification may be somethingthe user is (e.g. a biometric), something the user has (e.g. anelectronic key) or something the user knows (e.g. a PIN or password).For clarity and convenience, the description below primarily focuses ona password (e.g. a numeric or alpha-numeric string), but it should berecognized that description herein extends to other verificationinformation.

In one embodiment, the recipient verification module 326 receives aselection of the message identifier, determines whether to verify theuser's identity. Responsive to determining to verify the user'sidentity, the recipient verification module 326 requests and receivesverification information (e.g. a password) from the recipient anddetermines whether the received information (e.g. entered password)matches stored verification information (e.g. password associated withthe message or recipient). In one embodiment, the message retrievalmodule 322 retrieves the message based at least in part on whether therecipient verification module 326 determines that the receivedverification information matches the stored verification information. Inone embodiment, the message retrieval module 322 does not retrieve themessage when the recipient verification module 326 determines that thereceived verification information does not match stored verificationinformation.

In one embodiment, verification information is message-specific, i.e.,specific to an individual message or group of messages. For example, adifferent password may be associated with each individual message uponmessage creation (e.g. when the message receiver module 304 receives themessage). In one embodiment, verification information isrecipient-specific, i.e., specific to an individual recipient or groupof recipients. For example, a recipient (e.g. User 125 b) is associatedwith a first password, which the recipient (i.e. User 125 b) provides inorder access a message from a sender (e.g. User 125 a), and a secondpassword, which the recipient (i.e. User 125 b) provides in order accessa message from another sender (e.g. User 125 n). Depending on theembodiment, the verification information may be stored differently. Forexample, in one embodiment, message-specific verification informationmay be associated with that specific message and stored in associationwith the message in the non-persistent memory 207, andrecipient-specific verification information, in one embodiment, isstored in the data store 130 similar to a sender's credentials.

Depending on the embodiment, verification information may beauto-generated or sender defined. For example, in some embodiments, therecipient verification module 326 receives a password from the senderand associates the received password with a message, recipient or groupof recipients depending on the embodiment. In another example, in someembodiments, the recipient verification module 326 automaticallygenerates (e.g. randomly) a password and associates the generatedpassword with a message, recipient or group of recipients depending onthe embodiment.

In one embodiment, the recipient verification module 326 sendsverification information to the recipient using a traditional messagingservice (e.g. e-mail, instant message, social network post, micro-blogpost, SMS message, etc.). In one embodiment, the recipient verificationmodule 326 sends the verification information to the recipient using thesame traditional messaging service that is used to send the messageidentifier. For example, assume the message identifier was sent to therecipient via e-mail; in one embodiment, the recipient verificationmodule 326 sends a randomly generated password for that message in aseparate e-mail.

In one embodiment, the recipient verification module 326 sends theverification information to the recipient using a different traditionalmessaging service than is used to send the message identifier. Forexample, assume the message identifier was sent to the recipient viae-mail; in one embodiment, the recipient verification module 326 sends arandomly generated password for that message in an SMS text message.Such out-of-band communication of the verification may beneficiallyprovide additional security as the number of accounts or devices anunauthorized or unintended recipient would need to have access to inorder to retrieve the message is greater.

In some embodiments, the recipient verification module 326 may provide ahint associated with the verification information. For example, assumethe verification information is a sender-defined, message-specificpassword, in one embodiment, the recipient verification module 326prompts the user for a hint (e.g. provides a text field in which thesender may type a hint or security question), which is provided to therecipient so that the recipient may determine and provide the properverification information and successfully access the message. In anotherexample, assume the verification information is a recipient-specificpassword, in one embodiment, the recipient verification module 326provides a hint (e.g. provides a security question such as “What was thename of your first pet?”) so that the intended recipient may determineand provide the proper verification information and successfully accessthe message.

In one embodiment, the recipient verification module 326 provides a hintthat is sent with the message identifier. For example, a recipientreceives an e-mail with both a URL (i.e. message identifier) and “What'swas Tom's nickname freshman year?” (i.e. a hint). In another example, asocial network post on the sender's profile may include both a URL (i.e.message identifier) and “My favorite color” (i.e. a hint). Embodimentsin which a hint is provided with the message identifier may beneficiallyadd recipient verification to a message without needing to separatelycommunicate the verification information. For example, providingpassword hints with the message identifier allows such embodiments toutilize verification without using an out-of-band message (e.g.in-person or different electronic communication system) orout-of-message (e.g. by sending a second, separate e-mail).

It should be noted that, while the embodiment discussed herein has twomodules—the recipient verification module 326 which is discussedprimarily with regard to recipient verification and the authenticationmodule 240 is discussed primarily with regard to authenticating asender, in some embodiments, a single module may be used toauthenticate/verify both senders and recipients.

In one embodiment, the recipient verification module 326 passes theselected message identifier or an approval to retrieve the associatedmessage to the message retrieval module 322. For example, the recipientverification module 326 is communicatively coupled to the messageretrieval module 322 to send the selected message identifier or approvalto retrieve the associated message to the message retrieval module 322.In one embodiment, the recipient verification module 326 passes themessage identifier or approval to retrieve the associated message to themessage retrieval module 322. For example, the recipient verificationmodule 326 is communicatively coupled to the message retrieval module322 to send the message identifier or approval to retrieve theassociated message to the message retrieval module 322.

The record and notification module 328 includes code and routines forone or more of generating records of events and notifying users ofevents associated with the non-retained messaging system 100. In oneembodiment, the record and notification module 328 is a set ofinstructions executable by the processor 206. In another embodiment, therecord and notification module 328 is stored in the persistent memory205 and is accessible and executable by the processor 206. In eitherembodiment, the record and notification module 328 is adapted forcooperation and communication with the processor 206, other componentsof the NRM server 101 and other components of the non-retained messagingmodule 220.

In one embodiment, the record and notification module 328 generatesrecords of one or more events associated with the non-retained messagingsystem 100. Examples of events include, but are not limited to, thenon-retained messaging system's receipt of a message to be sent usingthe non-retained messaging system 100, selection of the messageidentifier by a recipient (i.e. request for retrieval of the message),successful delivery of the message to a recipient (i.e. complete messageretrieved and delivered to recipient's device), access of an attachmentassociated with the message, etc.

In one embodiment, the record and notification module 328 generates arecord of the non-retained messaging system's receipt of a message to besent using the non-retained messaging system 100. For example, therecord and notification module 328 generates a record when the messagereceiver module 304 receives a message. In one embodiment, the recordand notification module 328 generates a record in the form of a logentry. For example, the record and notification module 328 generates alog entry including one or more of the sender, the recipient, thelocation of the sender and the time of receipt of the message to besent. In one embodiment, the record and notification module 328generates a record in the form of a traditional message. For example,the record and notification module 328 generates and sends an e-mailcopy of the message to an e-mail address associated with the sender(e.g. the user's personal or corporate e-mail), so that the sender'se-mail inbox has a record of the messages sent by that user via thenon-retained messaging system 100. In another example, the record andnotification module 328 generates and sends an e-mail message describingthe message sent using the non-retained message system 100 (e.g. ane-mail describes the sender, recipient, content, etc., but does notactually include the content of the message sent using system 100).

In one embodiment, the record and notification module 328 generates arecord of selection of the message identifier by a recipient (i.e.request for retrieval of the message). For example, in one embodiment,the record and notification module 328 generates a record including therecipient, time and location of the selection. In one embodiment, a usermay request such a record (e.g. by selecting the message identifier orotherwise providing the message identifier) and receive the record forthat message from the record and notification module 328. Such anembodiment, may beneficially allow the user to verify whether therecipient requested the message.

In one embodiment, the record and notification module 328 generates arecord of successful delivery of the message to a recipient (i.e.complete message retrieved and delivered to recipient's device). Forexample, in one embodiment, the record and notification module 328generates a record including the recipient, time and recipient locationupon successful delivery of the message. In one embodiment, a user mayrequest such a record (e.g. by selecting the message identifier orotherwise providing the message identifier) and receive the record forthat message from the record and notification module 328. Such anembodiment, may beneficially allow the user to verify whether therecipient successfully received the message.

In one embodiment, the record and notification module 328 generates arecord for viewing of an attachment associated with the message. Forexample, in one embodiment, the record and notification module 328receives an attachment identifier responsive to a recipient opening (orotherwise viewing) an attachment and generates a record including therecipient, attachment identifier, time attachment was requested forviewing (i.e. opened) and the recipient's location. In one embodiment, auser may request such a record (e.g. by selecting the message identifieror otherwise providing the message identifier) and receive the recordfor that message from the record and notification module 328. Such anembodiment, may beneficially allow the user to verify whether therecipient viewed an attachment.

In one embodiment, sender controls whether the record and notificationmodule 328 generates a record for an event. For example, in oneembodiment, the sender may select preferences such that an e-mail copyof messages sent using the non-retained messaging system are sent to theuser's personal e-mail account. In another embodiment, an administratorcontrols whether the record and notification module 328 generates arecord for an event. For example, a company's administrator may controlwhether a copy of messages sent using the non-retained messaging system100 are sent to that employee's corporate e-mail or other corporatee-mail account for archiving/record keeping/auditing. In someembodiments, the administrator's settings supersede a sender's. Forexample, in one embodiment, an administrator may set controls such thatan e-mail copy of a message sent using the non-retained messaging system100 is sent to a corporate e-mail account (e.g. associated with thesender's group of users) and the sender may not override that setting orotherwise prevent the e-mail copy from being sent.

In one embodiment, the record and notification module 328 notifies auser of one or more events associated with the non-retained messagingsystem 100. For example, the record and notification module 328 sends ane-mail or other traditional message (e.g. a SMS text message) to amessage's sender responsive to the message retrieval module 322receiving a selection of the message identifier for that message. In oneembodiment, the sender may control whether an event triggers anotification and which traditional message system is used to send thenotification for that type of event. In one embodiment, an administratormay control whether an event triggers a notification and whichtraditional message system is used to send the notification for thattype of event.

As previously mentioned, although many of the examples herein primarilyreference e-mail (e.g. discuss an e-mail client, sending an identifiervia e-mail, etc.), it should be recognized that the disclosure hereinapplies to other messaging systems. For example, in one embodiment, asender (e.g. User A 125 a) using a messaging client 120 may draft asocial network post (e.g. a Facebook post) and the message storing andidentifier generation module 318 posts the message identifier (e.g. aURL) associated with that social network post under the sender's socialnetwork account (e.g. on User A's “wall”). In some embodiments, theposted message identifier may be accompanied by a text description orthe text description may serve as a hypertext link. When a user (who maybe the sender or another user such as a sender's friend) visits thesender's social networking site, the user is presented the post with themessage identifier (i.e. URL) and may select the message identifier(i.e., the user is a recipient) and the message retrieval module 322retrieves the social network post. Therefore, the social networkingmessage (i.e. the content) is no longer accessible after it is expungedfrom the non-retained message system 100 and, even if the social networkretains the posted message identifier indefinitely, the content is nolonger stored or accessible indefinitely. In some embodiments, therecipient verification module 326 cooperates with the social network'sprivacy settings (e.g. provides verification information to a set ofusers with permission from the social networking system to view thesender's social network posts) or supplements the privacy settings (e.g.recipient that is proven to be human, with permission from socialnetwork to view sender's social network wall and received amessage-specific password for the post may be presented the post).

In one embodiment, different instances of the non-retained messagingmodule 220 exist and each instance performs non-retained messaging for adifferent type of messaging service (e.g. non-retained messaging module220 for e-mail, non-retained messaging module 220 for social networks,etc.). In another embodiment, different instances of the non-retainedmessaging module 220 exist and each may accommodate a different providerwithin a type of messaging service, e.g., within social networking theremay be separate non-retained messaging modules 220 customized for eachof Google+, LinkedIn, Twitter, Facebook, etc. In yet another embodiment,a single instance of the non-retained messaging module 220 exists andeach may accommodate heterogeneous messaging services, e.g., when itreceives the message the non-retained messaging module 220 may determine(e.g. based on the messaging client 120) whether to send the messageidentifier as an e-mail or as a social network post and, if the latter,in which social network to post the message identifier.

Example Processes

FIGS. 4, 5 and 6A-B depict various methods 400, 500, 600 performed bythe system described above in reference to FIGS. 1-3.

FIG. 4 is a flow chart illustrating a method 400 for non-retainedelectronic messaging according to one embodiment. At block 402, themessage receiver module 304 of the non-retained messaging module 220receives a message from a sender's messaging client 120. At block 410,the message encryption module 316 optionally encrypts the messagereceived at block 402. At block 412, the message storing and identifiergeneration module 318 stores the message in non-persistent memory 207.At block 414, the message storing and identifier generation module 318generates and sends a message identifier associated with the messagestored at step 412. At block 418, the message retrieval module 322receives selection of the message identifier. Responsive to receivingthe selection of the message identifier at block 418, the messageretrieval module 322, at block 420, retrieves the message, decrypts themessage if encrypted at block 410, and sends the message forpresentation. At block 422, the expunging module 324 expunges themessage from the non-persistent memory 207.

FIG. 5 is a flow chart illustrating a method 500 for non-retainedelectronic messaging according to another embodiment. At block 502, themessage receiver module 304 of the non-retained messaging module 220receives a message from a sender's messaging client 120. At block 504,the key generation module 308 generates a globally unique key. At block506, the index generation module 310 optionally generates a globallyunique index. At block 508, the index hashing module 312 generates ahashed index based at least in part on the globally unique key generatedat block 504 and the globally unique index if generated at block 506. Atblock 510, the message encryption module 316 encrypts the message usingan encryption key based at least in part on the globally unique keygenerated at block 504. At block 512, the message storing and identifiergeneration module 318 stores the encrypted message in non-persistentmemory according to the hashed index generated at block 508. At block514, the message storing and identifier generation module 318 generatesand sends a message identifier which includes the globally unique keygenerated at block 504. When a globally unique index is generated atblock 506 and used to generate the hashed index at block 508, themessage identifier generated at block 514 also includes that globallyunique index. At block 516, information (e.g., the globally unique keygenerated at block 504, the globally unique index optionally generatedat block 506, the hashed index generated at block 508 and the messageidentifier generated at block 514) is expunged from the non-persistentmemory 207 by the expunging module 324. At block 518, the messageretrieval module 322 receives selection of the message identifier sentat block 514. Responsive to receiving the selection of the messageidentifier, at block 518, the message retrieval module 322 retrieves, atblock 520, the message and sends the message for presentation. At block522, the expunging module 324 expunges the message from thenon-persistent memory 207.

FIGS. 6A and 6B are flow charts illustrating a method 600 fornon-retained electronic messaging according to yet another embodiment.

At block 602, the message receiver module 304 of the non-retainedmessaging module 220 receives a message from a sender's messaging client120. At block 604, the authentication request module 306 requests andreceives authentication of the sender from an authorization server 107.At block 606, responsive to authentication at block 604, thenon-retained messaging module 220 retrieves sender preferences includinga message lifespan preference and sender identification preference. Atblock 608, the key generation module 308 generates a globally uniquekey. At block 610, the index generation module 310 optionally generatesa globally unique index. At block 612, the index hashing module 312generates a hashed index based at least in part on the globally uniquekey generated at block 608 and the globally unique index if generated atblock 610. At block 614, the message encryption module 316 encrypts themessage using an encryption key based at least in part on the globallyunique key generated at block 608. At block 616, the message storing andidentifier generation module 318 stores the encrypted message innon-persistent memory according to the hashed index. At block 618, theexpunging module 324 sets a timer associated with the message. At block620, the message storing and identifier generation module 318 generatesand sends a message identifier which includes the globally unique keygenerated at block 608. When a globally unique index is generated atblock 610 and used to generate the hashed index at block 612, themessage identifier generated at block 620 also includes that globallyunique index.

Referring now to FIG. 6B, at block 622, information (e.g., the globallyunique key generated at block 608, the globally unique index optionallygenerated at block 610, the hashed index generated at block 612, theencryption key used at block 614 and the message identifier generated atblock 620) is expunged from the non-persistent memory 207 by theexpunging module 324.

At block 624, the message retrieval module 322 determines whether aselection of the message identifier has been received. If the messageretrieval module 322 determines that a selection of the messageidentifier has been received (624—Yes), the method 600 continues atblock 629 or block 630 depending on the embodiment. When recipientverification is not performed, for the message associated with theselected identifier or generally, block 629 is skipped or omitted andthe method 600 continues at block 630. When recipient verification isperformed, for the message associated with the selected identifier orgenerally, the method 600 continues at block 629. At block 629, therecipient verification module 326 verifies the recipient and responsiveto successful verification of the recipient the method 600 continues atblock 630. At block 630, the message retrieval module 322 retrieves themessage and sends the message for presentation to the user. Theexpunging module 324 expunges, at block 632, the message from thenon-persistent memory 207, and the method 600 ends.

If the message retrieval module 322 determines that a selection of themessage identifier has not been received (624—No), the method 600continues at block 626. At block 626, the expunging module 324determines whether the user defined message lifespan has been met orexceeded. If the expunging module 324 determines that the user definedmessage lifespan has been met or exceeded (626—Yes), the method 600continues at block 632. If the expunging module 324 determines that theuser defined message lifespan has not been met or exceeded (626—No), themethod 600 continues at block 628.

At block 628, the expunging module 324 determines whether the systemdefined message lifespan has been met or exceeded. If the expungingmodule 324 determines that the system defined message lifespan has beenmet or exceeded (628—Yes), the method 600 continues at block 632. If theexpunging module 324 determines that the system defined message lifespanhas not been met or exceeded (628—No), the method 600 continues at block624. At block 632, the expunging module 324 expunges the message fromthe non-persistent memory 207, and the method 600 ends.

FIG. 7 is a flow chart illustrating a method 629 for verifying arecipient according to one embodiment. At block 702, the recipientverification module 326 of the non-retained messaging module 220receives a selected message identifier. At block 704, the recipientverification module 326 determines that the message associated with theselected message identifier received at block 702 requires recipientverification. At block 706, the recipient verification module 326verifies the humanity of the recipient. At block 708, the recipientverification module 326 verifies the identity of the recipient as theintended recipient (e.g. using verification information). It should benoted that method 629 verifies both the humanity and identity of therecipient as the intended receiver; however, other embodiments thatverify only humanity or only that the recipient is the intendedrecipient exist.

FIG. 8 is a flow chart illustrating a method 800 for generating a recordand notification of an event according to one embodiment. At block 802,the record and notification module 328 of the non-retained messagingmodule 220 detects an event in the non-retained messaging system 100. Atblock 804, the record and notification module 328 determines that thedetected event triggers generation of a record of that detected event.At block 806, the record and notification module 328 generates a recordof the detected event. At block 808, the record and notification module328 determines that the detected event triggers a notification of thedetected event. At block 810, the record and notification module 328determines a type of notification (e.g. e-mail, SMS, etc.). At block812, the record and notification module 328 generates and formats thenotification. At block 814, the record and notification module 328 sendsthe notification. It should be noted that while method 800 describes anevent that triggers both a record and a notification, in someembodiments, some events may trigger either a generation of a record ora notification to the user, but not both. It should also be noted thatwhile method 800 describes an event that triggers both a record and anotification, in some embodiments, the record and notification module328 may not provide one of the recordation functionality and thenotification functionality.

The foregoing description of the embodiments has been presented for thepurposes of illustration and description. It is not intended to beexhaustive or to limit the present embodiments to the precise formsdisclosed. Many modifications and variations are possible in light ofthe above teaching. It is intended that the scope of the presentembodiments be limited not by this detailed description, but rather bythe claims of this application. As will be understood by those familiarwith the art, the present embodiments may take other specific formswithout departing from the spirit or essential characteristics thereof.Likewise, the particular naming and division of the modules, routines,features, attributes, methodologies and other aspects are not mandatoryor significant, and the mechanisms that implement one embodiment or itsfeatures may have different names, divisions and/or formats.Furthermore, as will be apparent, the modules, routines, features,attributes, methodologies and other aspects of the embodiments can beimplemented as software, hardware, firmware or any combination of thethree. Also, wherever a component, an example of which is a module, isimplemented as software, the component can be implemented as astandalone program, as part of a larger program, as a plurality ofseparate programs, as a statically or dynamically linked library, as akernel loadable module, as a device driver, and/or in every and anyother way known now or in the future. Additionally, the embodiments arein no way limited to implementation in any specific programminglanguage, or for any specific operating system or environment.Accordingly, the disclosure is intended to be illustrative, but notlimiting, of the scope, which is set forth in the following claims.

What is claimed is:
 1. A method comprising: receiving, using one or morecomputing devices, a message; generating, using the one or morecomputing devices, a globally unique key; generating, using the one ormore computing devices, a hashed index based at least in part on theglobally unique key; storing, using the one or more computing devices,the message in a non-transitory, non-persistent memory of the one ormore computing devices using the hashed index; setting, using the one ormore computing devices, a timer used to determine whether a lifespanassociated with the message has been exceeded and is to be expunged fromthe one or more computing devices; generating, using the one or morecomputing devices, a message identifier, the message identifier based atleast in part on the globally unique key; sending, using the one or morecomputing devices, the message identifier to a recipient device;expunging, using the one or more computing devices, the globally uniquekey, the hashed index and the message identifier from the one or morecomputing devices responsive to sending the message identifier to therecipient device; receiving, using the one or more computing devices, aselection of the message identifier from the recipient device and theglobally unique key; retrieving, using the one or more computingdevices, the message from the non-transitory, non-persistent memory;sending the message to the recipient device for presentation; andexpunging, using the one or more computing devices, the message from theone or more computing devices subsequent to sending the message to therecipient device for presentation.
 2. The method of claim 1 furthercomprising: receiving, using the one or more computing devices, aresponse to a challenge; verifying, using the one or more computingdevices, that a user of the recipient device is human based on theresponse to the challenge; and wherein the message is retrieved from thenon-transitory, non-persistent memory based on the user being verifiedas human.
 3. The method of claim 1 further comprising: receiving, usingthe one or more computing devices, verification information from therecipient device; verifying, using the one or more computing devices,that a user of the recipient device is an intended recipient; andwherein the message is retrieved from the non-transitory, non-persistentmemory based on the user being verified as an intended recipient.
 4. Themethod of claim 3 further comprising: sending a hint for correctverification information with the message identifier.
 5. The method ofclaim 3 further comprising: sending the message identifier andverification information separately.
 6. The method of claim 1 whereinone or more of the message identifier and the message are sentanonymously.
 7. The method of claim 1 wherein the message identifier issent to a recipient device as one or more of an e-mail to a recipientuser, a text message to a recipient user's phone number and a postassociated with a sending user's social network site.
 8. The method ofclaim 1 further comprising: detecting, using the one or more computingdevices, an event; determining, using the one or more computing devices,whether the detected event triggers one or more of a generation of arecord of the event and a notification of the event to a user; andgenerating, using the one or more computing devices, one or more of therecord of the event and the notification of the event based on thedetermination.
 9. The method of claim 1 further comprising: receiving,using the one or more computing devices, a retraction request includingthe message identifier of the message to be retracted; identifying,using the one or more computing devices, the message in anon-transitory, non-persistent memory of the one or more computingdevices based on the message identifier; and expunging, using the one ormore computing devices, the message from the one or more devicesresponsive to receiving the retraction request, wherein the message isno longer available for retrieval and sending to the recipient deviceresponsive to receiving the retraction request.
 10. A non-transitorystorage medium including instructions that when executed by a computingdevice cause the computing device to: receive a message; generate aglobally unique key; generate a hashed index based at least in part onthe globally unique key; store the message in a non-transitory,non-persistent memory of the computing device using the hashed index;set a timer used to determine whether a lifespan associated with themessage has been exceeded and is to be expunged from the one or morecomputing devices; generate a message identifier, the message identifierbased at least in part on the globally unique key; send the messageidentifier to a recipient device; expunge the globally unique key, thehashed index and the message identifier from the one or more computingdevices responsive to sending the message identifier to the recipientdevice; receive a selection of the message identifier from the recipientdevice and the globally unique key; retrieve the message from thenon-transitory, non-persistent memory; send the message to the recipientdevice for presentation; and expunge the message from the one or moredevices responsive to sending the message to the recipient device forpresentation.
 11. A system comprising: a hardware processor; and amemory, the memory storing instructions that, when executed by thehardware processor, cause the system to: receive a message; generate aglobally unique key; generate a hashed index based at least in part onthe globally unique key; store the message in a non-transitory,non-persistent memory using the hashed index; set a timer used todetermine whether a lifespan associated with the message has beenexceeded and is to be expunged from the non-transitory, non-persistentmemory; generate a message identifier, the message identifier based atleast in part on the globally unique key; send the message identifier toa recipient device; expunge the globally unique key, the hashed indexand the message identifier responsive to sending the message identifierto the recipient device; receive a selection of the message identifierfrom the recipient device and the globally unique key; retrieve themessage from the non-transitory, non-persistent memory; send the messageto the recipient device for presentation; and expunge the message fromthe non-transitory, non-persistent memory subsequent to sending themessage to the recipient device for presentation.
 12. The system ofclaim 11, further comprising instructions that cause the system to:receive a response to a challenge and verifying that a user of therecipient device is human based on the response to the challenge; andwherein the message is retrieved from the non-transitory, non-persistentmemory based on the user being verified as human.
 13. The system ofclaim 11, further comprising instructions that cause the system to:receive verification information from the recipient device and verifyingthat a user of the recipient device is an intended recipient; andwherein the message is retrieved from the non-transitory, non-persistentmemory based on the user being verified as an intended recipient. 14.The system of claim 11, wherein the message identifier and hint forcorrect verification information are sent together.
 15. The system ofclaim 11, wherein the message identifier and verification informationare sent separately.
 16. The system of claim 11 wherein one or more ofthe message identifier and the message are sent anonymously.
 17. Thesystem of claim 11 wherein the message identifier is sent to a recipientdevice as one or more of an e-mail to a recipient user's e-mail, a textmessage to a recipient user's phone number and a post to a sendinguser's social network site.
 18. The system of claim 11, furthercomprising instructions that cause the system to: detect an event,determine whether the detected event triggers one or more of ageneration of a record of the event and a notification of the event to auser, and generate one or more of the record of the event and thenotification of the event based on the determination.